@Greenheart is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

I hope a low download count is not a blocker for adding new, high quality packages like this one.

I think that it would be unfortunately. There are just too many packages for us to be able to test and evaluate them all, so we have to rely on a few filters in order to select from a smaller set of packages

I think that it would be unfortunately. There are just too many packages for us to be able to test and evaluate them all, so we have to rely on a few filters in order to select from a smaller set of packages.

While I agree that the packages should be of high quality and thus need thorough review, I think this creates an unfortunate dynamic for up-and-coming projects of high quality that would benefit from the visibility and community feedback. Encouraging the ecosystem to improve rather also makes the entire ecosystem better off. If we're not careful svelte.dev might "recommend" older packages just because they are tried and trusted (based on popularity) when there might be better alternatives (based on technical merits) that take advantage of newer APIs in Svelte/Vite/DOM.

For markdoc-svelte, I can personally vouch for the package quality after using it in several projects and reviewing the source code. Also looking at the m3-svelte package, that one doesn't have that many more stars and downloads compared to markdoc-svelte: https://github.com/sveltejs/svelte.dev/pull/1592/files#diff-8398f3534bbf7138cc626b60d490018629ddde7d2044c8a6e387f5161a6edd1eR8-R9

Just like it's valuable to showcase a Material Design component library alongside other component libraries, adding a Markdoc package is a valuable addition to show Svelte has good support for more than Markdown.

With that said, I hope you will reconsider merging this. If not, that's unfortunate but I guess we'll just have to do some marketing. And a disclaimer - I'm not the original author of markdoc-svelte, just a happy user and small contributor :)

Proposal for handling similar cases in the future

What if the svelte.dev packages also included smaller projects as long as they meet a high quality? Perhaps a dedicated section for up-and-coming packages that is clearly labelled like "Explore up-and-coming packages". As long as packages meet a high quality and at least a few people in the community support it by for example voting and commenting on a GitHub issue, the package would be included in the "up-and-coming" section.

This could use a GitHub issue template in the svelte.dev repo, and a dedicated issue label to make it easy for the community to suggest new packages and discuss why the package should be added. We also need clear rules for packages which packages are included, so we have a common understanding of when to add packages - and when to remove them due to inactivity or similar reasons.

If a wider range of Svelte ecosystem projects get visibility and usage, they will benefit from feedback and development, which ultimately will help the Svelte ecosystem grow and improve faster.

If we don't deal with this dynamic, this situation would risk becoming a prime example of the systems trap Success to the successful - Competitive Exclusion, as described on page 126 of the book Thinking in Systems. The language of the screenshot-quote below is a bit extreme in this context, but I hope you get the point. We will all benefit from a diverse and thriving ecosystem - and diversity needs active support to not just point everyone to the most popular packages when there might be alternative solutions out there. Better solutions based on technical merits and new perspectives, rather than what is already popular.

This should probably be a separate issue.